扩展测试为什么难模拟 vscode 模块？

结论

vscode 不是一个普通 npm 包，类型包里几乎没有可运行的实现。API 由扩展宿主在运行时注入。单测里把整个模块 mock 掉既脆又容易测偏，所以核心行为用真实扩展宿主做集成测试。

展开

官方路径是 @vscode/test-cli 配 @vscode/test-electron。它会下载或使用指定版本的 VS Code，启动扩展开发宿主，加载你的测试入口。测试代码和插件跑在同一个宿主里，可以真实调用 workspace.openTextDocument、命令和诊断。

适合放进这种测试的：

• 命令是否注册、执行后文档变成什么样
• 诊断在示例文件上是否出现
• 配置作用域、多根的基本行为

不适合：

• 纯函数、协议报文拼装、范围计算。这些不要依赖 vscode，抽成普通模块用单测
• 需要登录、真实远程机器的路径。用假服务和示例仓库

硬 mock 的问题：

• API 表面大，而且会随引擎版本变化
• 很多行为依赖宿主顺序，例如命令激活、when 上下文、文档版本
• mock 通过了，真宿主里 edit 回调必须同步这种约束仍会失败

如果某个函数只需要 Uri 和 Range，把算法和 vscode 类型隔开，输入输出用普通数据。插件入口再做薄适配。这样大部分逻辑不必启动编辑器。

CI 里跑扩展测试要准备好桌面依赖或用可无头运行的方式，并锁住 engines 对应的编辑器版本。版本漂移是测试偶发失败的常见来源。

容易讲错的点

• @types/vscode 不能在 Node 里 import 出可用 API。
• 集成测试比单测慢，所以不要把所有字符串断言都塞进宿主测试。
• 测试里改用户设置要注意隔离，别写进开发者自己的全局设置。用测试工作区。